…tion which also takes a lock.

…eliminate

exclusive mutex acquisition in the read-only write_queue_size() method, which is
called on every read cycle in start_read_message.

thread pool, saving the received QC immediately on the critical path
before fork_db_.add(). Only consider_voting is posted asynchronously.
Eliminates thread pool scheduling delay from block processing latency.

…ueued message

Replace the std::function<void(ec, size_t)> callback in queued_write with
concrete struct fields (connection_id, close_after_send, net_msg, block_num)
and inline the callback logic into clear_out_queue. This removes the per-message
heap allocation caused by the lambda closure exceeding std::function's SBO limit,
along with the shared_from_this() refcount bump/release in enqueue_buffer.

At 10K TPS with 25 peers: eliminates ~250K heap alloc/dealloc pairs and ~500K
atomic refcount operations per second.

…th stack-local small_vector.

peer_connections() returned connection_id_set (unordered_flat_set<uint32_t>) by value,
heap-allocating on every transaction broadcast. Switch return type to
boost::container::small_vector<connection_id_t, 64> which holds up to 64 connection IDs
(256 bytes) on the caller's stack frame via RVO, avoiding heap allocation in the common case.

…cast hot paths.

Every transaction/vote broadcast previously posted a lambda per peer to its
strand, heap-allocating ~64 bytes and copying two shared_ptrs (8 atomic ops
per peer). At 25 peers and 1000 TPS this was 25K heap allocs/s + 200K atomic
ops/s.

add_write_queue is already mutex-protected, and _out_queue.empty() under the
same lock atomically tells us whether an async_write completion handler will
drain the queue. When a write IS in flight, newly queued messages are picked
up automatically — no strand post needed. When the connection is idle, a
single coalesced drain post (guarded by _write_drain_pending atomic in
queued_buffer) kicks do_queue_write.

Every inbound packed_transaction triggers make_shared + fc::raw::unpack +
reflector_init (6-8 heap allocations) before checking the dedup cache. In a
gossip network most messages are duplicates, so these allocations are created
and immediately freed — ~24K-32K allocator calls/s wasted at 2000 dups/s.

Add a fast path in process_next_trx_message that peeks the wire bytes via
mb_peek_datastream and computes the transaction ID directly from the packed_trx
SHA-256 hash without deserializing. For the common case (k1/r1/em/ed signatures,
compression_type::none), this identifies duplicates with zero heap allocations.

- trx_dedup.hpp: templated parse_trx_dedup_info() skips signatures by known
  fixed sizes, reads compression byte, skips context_free_data, then hashes
  packed_trx bytes via sha256::encoder + 512-byte stack buffer. static_assert
  guards against new signature types and transaction_header field reordering.
- dispatch_manager::have_txn(): read-only local_txns lookup (no insertion,
  no connection_id tracking, at worst causes one redundant notice to this peer).
- connection::try_early_dedup(): peek-parse-check-consume pipeline, falls back
  to the full unpack path for webauthn/bls signatures, zlib compression, or
  any parse error.

This reverts commit 5f99839.

…g calls.

Replace packed_transaction with transaction_message{id, trx}.
The sender prepends the 32-byte transaction ID before the packed_transaction
payload; the receiver peeks those bytes and checks the dedup table before any heap
allocation. Duplicate transactions (the common case in gossip) now skip
make_shared + unpack + reflector_init entirely, eliminating
~6-8 heap allocations per duplicate (~24K-32K wasted calls/s at 2000 dups/s).

Every inbound vote_message triggers make_shared<vote_message>() + full
fc::raw::unpack including two BLS Montgomery field conversions (~1.1 us)
before any duplicate check. In a 21-finalizer network with only 10 peers,
~378 duplicate votes/s arrive, each wasting CPU on deserialization that
is immediately discarded.

Same pattern as the transaction_message optimization: prepend a 32-byte
vote_id (SHA-256 of block_id || strong || finalizer_key, excluding the
signature which is deterministic) on the wire. The receiver peeks the ID,
checks a bounded dedup cache, and only deserializes for new votes.

- protocol.hpp: add vote_id_type alias and compute_vote_id() helper
- buffer_factory.hpp: add vote_buffer_factory (prepends vote_id on wire)
- net_plugin.cpp: add vote_dedup multi_index cache to dispatch_manager
  with hashed_unique<vote_id> + ordered_non_unique<block_num> indices;
  restructure process_next_vote_message() to peek-and-check before
  deserialization; validate wire vote_id matches computed on full path;
  prune cache entries in expire_blocks() at LIB advancement

…oadcast path.

…as sent the transaction, preventing redundant rebroadcasts back to the same peer and keeping per-connection tracking consistent.

The vote_id was being inserted into the dedup cache before chain
validation (BLS signature, finality rules). A malformed vote could
poison the cache and cause valid votes with the same
(block_id, strong, key) tuple to be silently dropped.

The post-validation path in bcast_vote_message already calls
add_vote_id on success, so the early insert was redundant for valid
votes. Removing it ensures only chain-validated votes enter the cache.